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Additional Media Type Structured Syntax Suffixes 
Abstract 


A content media type name sometimes includes partitioned meta- 
information distinguished by a structured syntax to permit noting an 
attribute of the media as a suffix to the name. This document 
defines several structured syntax suffixes for use with media type 
registrations. In particular, it defines and registers the "+json", 
"t+tber", "t+der", "+fastinfoset", "+twbxml" and "+zip" structured syntax 
suffixes, and provides a media type structured syntax suffix 
registration form for the "+xml" structured syntax suffix. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6839. 
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1. Introduction 


[RFC3023] created the +xml suffix convention that can be used when 
defining names for media types whose representation uses XML 
underneath. That is, they could have been successfully parsed as if 
the media type had been application/xml in addition to their being 
parsed as their media type that is using the +xml suffix. [RFC6838] 
defines the media type "Structured Syntax Suffix Registry" to be used 
for such structured syntax suffixes. 


A variety of structured syntax suffixes have already been used in 
some media type registrations, in particular "+json", "+der", 
"+fastinfoset", and "+wbxml". This document defines and registers 
these structured syntax suffixes in the Structured Syntax Suffix 
Registry, along with "tber" and "+zip". In addition, this document 
updates [RFC3023] to formally register the "+xml" structured syntax 
suffix according to the procedure defined in [RFC6838]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. When to Use These Structured Syntax Suffixes 


Each of the structured syntax suffixes defined in this document is 
appropriate for use when the media type identifies the semantics of 
the protocol payload. That is, knowing the semantics of the specific 
media type provides for more specific processing of the content than 
that afforded by generic processing of the underlying representation. 


At the same time, using the suffix allows receivers of the media 
types to do generic processing of the underlying representation in 
cases where 


they do not need to perform special handling of the particular 
semantics of the exact media type, and 


there is no special knowledge needed by such a generic processor 
in order to parse that underlying representation other than what 
would be needed to parse any example of that underlying 
representation. 
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3. Initial Structured Syntax Suffix Definitions 
3.1. The +json Structured Syntax Suffix 


[RFC4627] defines the "application/json" media type. The suffix 
"+json" MAY be used with any media type whose representation follows 
that established for "application/json". The media type structured 
syntax suffix registration form follows. See [RFC6838] for 
definitions of each of the registration form headings. 


Name: JavaScript Object Notation (JSON) 

t+tsuffix: + json 

References: [RFC4627] 

Encoding considerations: 
Per [RFC4627], JSON is allowed to be represented using UTF-8, 
UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit 
compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32, 
JSON is binary ([RFC2045]). 

Fragment identifier considerations: 
The syntax and semantics of fragment identifiers specified for 
+json SHOULD be as specified for "application/json". (At 
publication of this document, there is no fragment identification 


syntax defined for "application/json".) 


The syntax and semantics for fragment identifiers for a specific 
"xxx/yyyt+json" SHOULD be processed as follows: 


For cases defined in +json, where the fragment identifier resolves 
per the +json rules, then process as specified in + json. 


For cases defined in +json, where the fragment identifier does 
not resolve per the +json rules, then process as specified in 


"xxx/yyytjson". 


For cases not defined in +json, then process as specified in 


"xxx/yyytjson". 
Interoperability considerations: n/a 
Security considerations: See [RFC4627] 


Contact: Apps Area Working Group (apps-discuss@ietf.org) 
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Author/Change controller: 


The Apps Area Working Group. IESG has change control over this 
registration. 


3.2. The +ber Structured Syntax Suffix 
The ITU defined the Basic Encoding Rules (BER) transfer syntax in 
[ITU.X690.2008]. The suffix "+ber" MAY be used with any media type 
whose representation follows the BER transfer syntax. (The Expert 
Reviewer for media type structured syntax suffix registrations ought 
to be aware of the relationship between BER and DER to aid in 
selecting the proper suffix.) The media type structured syntax 
suffix registration form for +ber follows: 
Name: Basic Encoding Rules (BER) transfer syntax 
+suffix: +ber 
References: [ITU.X690.2008] 
Encoding considerations: BER is a binary encoding. 


Fragment identifier considerations: 


At publication of this document, there is no fragment 
identification syntax defined for +ber. 


The syntax and semantics for fragment identifiers for a specific 
"xxx/yyytber" SHOULD be processed as follows: 


For cases defined in +ber, where the fragment identifier 
resolves per the +ber rules, then process as specified in +ber. 


For cases defined in +ber, where the fragment identifier does 
not resolve per the +ber rules, then process as specified in 


"xxx/yyytber". 


For cases not defined in +tber, then process as specified in 
"xxx/yyytber". 


Interoperability considerations: n/a 
Security considerations: 


Each individual media type registered with a +ber suffix can have 
additional security considerations. 
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BER has a type-length-value structure, and it is easy to construct 
malicious content with invalid length fields that can cause buffer 
overrun conditions. 


BER allows for arbitrary levels of nesting, which may make it 
possible to construct malicious content that will cause a stack 
overflow. 
Interpreters of the BER structures should be aware of these issues 
and should take appropriate measures to guard against buffer 
overflows and stack overruns in particular and malicious content 
in general. 
Contact: Apps Area Working Group (apps-discuss@ietf.org) 
Author/Change controller: 


The Apps Area Working Group. IESG has change control over this 
registration. 


3.3. The +der Structured Syntax Suffix 
The ITU defined the Distinguished Encoding Rules (DER) transfer 
syntax in [ITU.X690.2008]. The suffix "+tder" MAY be used with any 
media type whose representation follows the DER transfer syntax. 
(The Expert Reviewer for media type structured syntax suffix 
registrations ought to be aware of the relationship between BER and 
DER to aid in selecting the proper suffix.) The media type 
structured syntax suffix registration form for +der follows: 
Name: Distinguished Encoding Rules (DER) transfer syntax 
+suffix: +der 
References: [ITU.X690.2008] 
Encoding considerations: DER is a binary encoding. 


Fragment identifier considerations: 


At publication of this document, there is no fragment 
identification syntax defined for +der. 


The syntax and semantics for fragment identifiers for a specific 
"xxx/yyy+der" SHOULD be processed as follows: 


For cases defined in +der, where the fragment identifier 
resolves per the +der rules, then process as specified in +der. 
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For cases defined in +der, where the fragment identifier does 
not resolve per the +der rules, then process as specified in 


"xxx/yyytder". 
For cases not defined in +der, then process as specified in 
"xxx/yyytder". 

Interoperability considerations: n/a 


Security considerations: 


Each individual media type registered with a +der suffix can have 
additional security considerations. 


DER has a type-length-value structure, and it is easy to construct 
malicious content with invalid length fields that can cause buffer 
overrun conditions. 


DER allows for arbitrary levels of nesting, which may make it 
possible to construct malicious content that will cause a stack 
overflow. 


Interpreters of the DER structures should be aware of these issues 
and should take appropriate measures to guard against buffer 
overflows and stack overruns in particular and malicious content 
in general. 


Contact: Apps Area Working Group (apps-discuss@ietf.org) 
Author/Change controller: 


The Apps Area Working Group. IESG has change control over this 
registration. 


3.4. The +fastinfoset Structured Syntax Suffix 


The ITU defined the Fast Infoset document format as a binary 
representation of the XML Information Set in [ITU.X891.2005]. These 
documents further define the "application/fastinfoset" media type. 
The suffix "+fastinfoset" MAY be used with any media type whose 
representation follows that established for "application/ 
fastinfoset". The media type structured syntax suffix registration 
form follows: 


Name: Fast Infoset document format 


+suffix: +fastinfoset 
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References: [ITU.X891.2005] 

Encoding considerations: 
Fast Infoset is a binary encoding. The binary, quoted-printable, 
and base64 content-transfer-encodings are suitable for use with 
Fast Infoset. 

Fragment identifier considerations: 
The syntax and semantics of fragment identifiers specified for 
+fastinfoset SHOULD be as specified for "application/fastinfoset". 
(At publication of this document, there is no fragment 


identification syntax defined for "application/fastinfoset".) 


The syntax and semantics for fragment identifiers for a specific 
"xxx/ yyytfastinfoset" SHOULD be processed as follows: 


For cases defined in +fastinfoset, where the fragment 
identifier resolves per the +fastinfoset rules, then process as 
specified in +fastinfoset. 

For cases defined in +fastinfoset, where the fragment 
identifier does not resolve per the +fastinfoset rules, then 


process as specified in "xxx/yyyt+fastinfoset". 


For cases not defined in +fastinfoset, then process as 
specified in "xxx/ yyy+fastinfoset". 


Interoperability considerations: n/a 

Security considerations: 
There are no security considerations inherent in Fast Infoset. 
Each individual media type registered with a +fastinfoset suffix 
can have additional security considerations. 

Contact: Apps Area Working Group (apps-discuss@ietf.org) 


Author/Change controller: 


The Apps Area Working Group. IESG has change control over this 
registration. 
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3.5. The +wbxml Structured Syntax Suffix 


The Wireless Application Protocol (WAP) Forum has defined the WAP 
Binary XML (WBXML) document format as a binary representation of XML 
in [WBXML]. This document further defines the "application/ 
vnd.wap.wbxml" media type. The suffix "+wbxml" MAY be used with any 
media type whose representation follows that established for 
"application/vnd.wap.wbxml". The media type structured syntax suffix 
registration form follows: 


Name: WAP Binary XML (WBXML) document format 

+tsuffix: +wbxml 

References: [WBXML ] 

Encoding considerations: WBXML is a binary encoding. 

Fragment identifier considerations: 
The syntax and semantics of fragment identifiers specified for 
+wbxml SHOULD be as specified for "application/vnd.wap.wbxml". 
(At publication of this document, there is no fragment 


identification syntax defined for "application/vnd.wap.wbxml".) 


The syntax and semantics for fragment identifiers for a specific 
"xxx/yyyt+twbxml" SHOULD be processed as follows: 


For cases defined in +wbxml, where the fragment identifier 
resolves per the +wbxml rules, then process as specified in 
+wbxml. 

For cases defined in +wbxml, where the fragment identifier does 
not resolve per the +wbxml rules, then process as specified in 


"xxx/yyytwbxml". 


For cases not defined in +wbxml, then process as specified in 
"xxx/yyytwbxml". 


Interoperability considerations: n/a 

Security considerations: 
There are no security considerations inherent in WBXML. Each 
individual media type registered with a +twbxml suffix can have 


additional security considerations. 


Contact: Apps Area Working Group (apps-discuss@ietf.org) 
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Author/Change controller: 


The Apps Area Working Group. IESG has change control over this 
registration. 


3.6. The +zip Structured Syntax Suffix 
The ZIP format is a public domain, cross-platform, interoperable file 
storage and transfer format, originally defined by PKWARE, Inc.; it 
supports compression and encryption and is used as the underlying 
representation by a variety of file formats. The media type 
"application/zip" has been registered for such files. The suffix 
"+zip" MAY be used with any media type whose representation follows 
that established for "application/zip". The media type structured 
syntax suffix registration form follows: 
Name: ZIP file storage and transfer format 
t+tsuffix: +zip 
References: [ZIP] 


Encoding considerations: ZIP is a binary encoding. 


Fragment identifier considerations: 


The syntax and semantics of fragment identifiers specified for 
+zip SHOULD be as specified for "“application/zip". (At 
publication of this document, there is no fragment identification 
syntax defined for "application/zip".) 


The syntax and semantics for fragment identifiers for a specific 
"xxx/yyyt+zip" SHOULD be processed as follows: 


For cases defined in +zip, where the fragment identifier 
resolves per the +zip rules, then process as specified in +zip. 


For cases defined in +zip, where the fragment identifier does 
not resolve per the +zip rules, then process as specified in 


"xxx/yyytzip". 
For cases not defined in +zip, then process as specified in 
"xxx/yyytzip". 

Interoperability considerations: n/a 
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Security considerations: 


IP files support two forms of encryption: Strong Encryption and 
AES 128-bit, 192-bit, and 256-bit encryption; see the 


specification for further details. Each individual media type 
registered with a +zip suffix can have additional security 
considerations. 


Contact: Apps Area Working Group (apps-discuss@ietf.org) 


Author/Change controller: The Apps Area Working Group. IESG has 
change control over this registration. 


4. IANA Considerations 


See the media type structured syntax suffix registration forms in 
Sections 3.1 - 3.6. 


4.1. The +xml Structured Syntax Suffix 


The following structured syntax suffix registration for "+xml" shall 
be used to reflect the information found in [RFC3023], with the 
addition of fragment identifier considerations. (Note that [RFC3023] 
is in the process of being updated by [XML-MEDIATYPES].) 


Name: Extensible Markup Language (XML) 

+suffix: +xml 

References: [RFC3023] 

Encoding considerations: 
Per [RFC3023], XML is allowed to be represented using both 7-bit 
and 8-bit encodings. When XML is written in UTF-8, XML is 8bit 
compatible ([RFC2045]). When XML is written in UTF-16 or UTF-32, 
XML is binary ([RFC2045]). 

Fragment identifier considerations: 
The syntax and semantics of fragment identifiers specified for 
+xml SHOULD be as specified for "application/xml". (At 
publication of this document, the fragment identification syntax 


considerations for "application/xml" are defined in [RFC3023], 
Sections 5 and 7.) 
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The syntax and semantics for fragment identifiers for a specific 
"xxx/yyy+xml" SHOULD be processed as follows: 


For cases defined in +xml, where the fragment identifier 
resolves per the +xml rules, then process as specified in +xml. 


For cases defined in +xml, where the fragment identifier does 
not resolve per the +xml rules, then process as specified in 
"xxx/yyytxml". 


For cases not defined in +xml, then process as specified in 
"xxx/yyytxml". 


Interoperability considerations: See [RFC3023]. 

Security considerations: See [RFC3023] 

Contact: Apps Area Working Group (apps-discuss@ietf.org) 
Author/Change controller: 


The Apps Area Working Group. IESG has change control over this 
registration. 


5. Security Considerations 


See the Security Considerations sections found in the media type 
structured syntax suffix registration forms from Sections 3 and 4. 


When updating a +<suffix> registration, care should be taken to 
review all previously-registered xxx/yyy+<suffix> media types as to 
whether they might be affected by the updated +<suffix> registration. 
Because the generic fragment identifier processing rules take 
precedence over media-type-specific rules, introducing new or 
changing existing definitions may break the existing registrations of 
specific media types, as well as particular implementations of 
applications that process affected media types. Such changes can 
introduce interoperability and security issues. 


When updating the fragment identifier processing rules for a specific 
xxx/yyyt<suffix> media type, care should be taken to review the 
generic fragment identifier processing rules for the +<suffix> 
registration and not introduce any conflicts. Because the generic 
fragment identifier processing rules take precedence over media-type- 
specific rules, such conflicting processing requirements should be 
ignored by an implementation, but such conflicts can introduce 
interoperability and security issues. 
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[FRAGID-BP] provides additional advice to designers of 


fragment identifier rules for media type suffixes and specific media 


types. 
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